1. Field of the Invention
The present invention relates generally to virtual storage management in computer systems. More particularly, the present invention relates to the layout and management of shared virtual storage within a virtual memory system including both a private space and a shared space.
2. Description of the Related Art
The use of virtual storage in computer systems, including the use of multiple virtual spaces within a given system to isolate data owned by separate processes, is widespread. This is exemplified in operating systems such as the IBM z/OS™ operating system and described in the IBM publication z/OS MVS Initialization and Tuning Guide, SA22-7591-01 (March 2002), incorporated herein by reference.
It is common in virtual storage environments that address translation is performed in a hierarchical fashion. Groups of bits from the virtual address serve as indices to fetch real storage addresses from a dynamic address translation (DAT) table for the next layer of translation and eventually locate the real storage location for the virtual address itself. These DAT tables may be referred to generically as page tables, although in the IBM z/Architecture™ they are most recently referred to as region, segment and page tables, depending on which level is being referenced. The number of levels of tables in the most recent version of the z/Architecture may be two, three, four, or five, depending on the amount of virtual storage that is to be mapped. This is described in the IBM publication z/Architecture Principles of Operation, SA22-7832-01 (October 2001), incorporated herein by reference.
To perform address translation the machine hardware sequentially fetches from each table in order to proceed to the next layer of translation. To avoid this overhead for each address translation, it is common for there to be a hardware translation buffer or cache, in which the results (or partial results) of prior address translations are saved. This has been described in such articles as “Two Level Translation” by A. Rutchka, Vol. 13, No. 8, January 1971, of the IBM Technical Disclosure Bulletin, and “Dynamic Address Translation for Multiprocessing System” by W. Spruth, Vol. 14, No. 5, October 1971, of the IBM Technical Disclosure Bulletin. Depending on the locality of reference, the size of the hardware translation buffer, and the algorithms used to decide which addresses to keep when the hardware translation buffer is full, there is a lesser or greater amount of address translation overhead associated with program execution. For this reason, operating system designers are highly motivated to minimize the number of levels of address translation wherever this is an option.
In prior systems of z/OS and earlier technologies such as OS/390™, MVS/ESA™, MVS/XA™, and the like, the virtual address space consisted of a private space and a common area straddling 16 MB (224 bytes) which was actually shared across all address spaces. (In this application, as is customary in discussions of storage addresses, multipliers such as kilo- (K), mega- (M), giga- (G) and the like refer to powers of 2 rather than to powers of 10. Thus, a kilobyte (KB) means 210 rather than 103 bytes, a megabyte (MB) means 220 rather than 106 bytes, and a gigabyte (GB) means 230, not 109, bytes.) As for all sharing technologies, sharing is accomplished by using the same real frame for a given page across multiple address spaces. In the case of the common area, all common segments are mapped by a set of common page tables which are pointed to by the appropriate entries in the segment tables of each address space. In this common area are system (or kernel) code and control structures, together with authorized code and control structures. Page tables (and segment tables) in these prior systems are virtualized and hence consume some 8 MB of pre-allocated virtual space within each private space. In order to provide access to the common space, the segment table entries for the common segments are identical in content for each address space.
The earliest data sharing in these systems was via the common area, but this is only available to privileged code. Later, general data sharing was provided on a page-oriented basis which was able to give different access modes (read/write vs. read-only for example) to different views using hardware-enforced protection bits in the page table entry. This was adequate for small ranges, but resulted in undesirable overhead to track the states of the pages within a data sharing group once the amount of shared data grew. This was followed in later releases by facilities for data sharing in segment-oriented ranges, so that the entire page table could be shared. In this case, a segment table entry would record the address of the shared page table so that two or more address spaces could share the same segment. These techniques were limited to address ranges below 2 GB (231 bytes) due to the underlying architecture present at the time these services were introduced.
With the introduction of 64-bit addressing in z/OS, there was a desire to provide a more efficient data sharing facility which scaled with the tremendous expansion of addressability provided by doubling the address width. Continued use of virtualized DAT tables would consume approximately 256 bytes for the full 64-bit addressing capability; there are 244 segments and each segment requires a 4 KB (4,096-byte) page table in the z/Architecture. To avoid this huge loss of virtual space for virtual storage management purposes a new approach was highly desirable. Part of this z/Architecture provides for the ability to reference real storage addresses directly, even while running in a DAT-enabled mode. This is described in commonly owned U.S. Pat. No. 5,479,631, entitled “System for Designating Real Main Storage Addresses in Instructions While Dynamic Address Translation Is On”, as well as in the previously referenced z/Architecture publication. With this facility it is possible for the operating system to provide virtual storage management, including the updating of DAT tables without removing virtual storage from the application's pool of virtual addressability. This technology to use unvirtualized DAT tables has been available in z/OS since Release 1.2.